Many of today's operating systems manage the allocation of space on mass storage devices by partitioning this space into volumes. The term volume refers to a logical grouping of physical storage space elements which are spread across multiple disks and associated disk drives, as in a redundant array of inexpensive disks (RAID). Volumes are part of an abstraction which permits a logical view of storage as opposed to a physical view of storage. As such, most operating systems see volumes as if they were independent disk drives. Volumes are created and maintained by Volume Management Software. A volume group is a collection of distinct volumes that comprise a common set of drives.
A RAID controller may include a volume copy feature that is capable of replicating the entire contents of one volume to another volume. To use a volume copy feature, a user may specify an existing volume or create a new volume for use as a target volume for the volume copy operation. The volume to be copied is referred to as the source volume. The target volume generally requires a capacity at least as large as that of an existing source volume. Following the submission of a volume copy request to a RAID controller, the volume copy operation reads blocks of data from the source volume and writes the data to the target volume while managing the consumed controller hardware bandwidth to control the performance impact of the copy operation. During the copy operation, the source volume is not readable and the target volume is not readable or writable.
Snapshot technology has become a prevalent mechanism for ensuring data protection or supporting other tasks such as data mining and data cloning in today's mass storage systems, such as a RAID. “Snapshot” is a common industry term denoting the ability to of a RAID system to record the state of a base volume at a specified moment in time for the purpose of restoring the base volume to that state at a point in the future. The original copy of the data located on the base volume continues to be available to applications without interruption, while the snapshot copy is used to perform other functions on the data. Snapshots provide an excellent means of data protection as well as providing better application availability, faster recovery, easier back up management of large volumes of data, and reduced exposure to data loss.
One implementation of a snapshot volume system is the copy-on-write snapshot. In this implementation, a snapshot volume includes snapshot image repository sub-volumes. When the snapshot volume is first created, a snapshot image comprising only meta-data of the original base volume data is written to the snapshot image volume. No physical copy of the base volume data is made at the time of snapshot creation. Therefore, the creation of the snapshot is almost instantaneous. This meta-data image may comprise reference markers or pointers to data stored in the base volume.
The snapshot volume then tracks the changes to blocks of the original base volume as writes to the base volume are performed. Before a write to an original data block of the base volume is allowed, a copy-on-write protocol copies that original data block to the repository volume associated with a given snapshot image. This keeps the snapshot data consistent with the exact time the snapshot was taken. A given base volume data block is copied into the snapshot volume only upon receipt of the first write request for that data block following creation of the snapshot volume.
Following creation of a snapshot volume, certain applications, such as data protection, data analysis and reporting, and data replication applications may access the point-in-time data preserved by the snapshot. Read requests to the snapshot volume referencing base volume data blocks which are unchanged since the creation of the snapshot are redirected to the original base volume data. Read requests to the snapshot volume referencing base volume data blocks which have been copied from the base volume to the repository volume (via a copy-on-write) are directed to these copied blocks in the repository volume.
A common operation in such systems is the restoration of the base volume to the point-in-time state preserved by a snapshot. This restoration process is commonly known as rollback. Currently, snapshot rollback may be implemented as a firmware application associated with the snapshot management feature of a RAID controller.
Current RAID controllers maintain distinct snapshot rollback and volume copy firmware occupying valuable device resources. However, the ultimate result of a snapshot rollback and a volume copy of a snapshot volume is the same. Each results in the complete replication of a source volume (e.g. the snapshot volume) to a target volume (e.g. the base volume). Therefore, it would be desirable to provide a general purpose volume copy feature which could be used by a copy-on-write snapshot volume controller for snapshot rollback operations.
However, current implementations of volume copy features write the entire extent of a source volume to a target volume. As such, using the volume copy feature to copy the entire extent of a snapshot volume back to the base volume (i.e. a rollback) would entail writing all data previously copied to the snapshot volume via copy-on-write operations and all unaltered original base volume data. This writing of the entire extent of the snapshot to the base volume would, in turn, initiate copy-on-write operations of that entire extent to any currently associated snapshot volumes. As snapshot volumes are configured with storage capacities significantly smaller than their associated base volume, the copy-on-write of an entire snapshot volume would result in snapshot volume overflows and corresponding data loss.
Current implementations of volume copy as a snapshot rollback mechanism employ a two-step process. In this process, the entire extent of a snapshot volume is copied to an intermediate volume and the snapshot volume is then deleted. The intermediate volume is then copied to the original base volume. While this scheme is effective at preventing copy-on-write overflow with respect to the subject snapshot volume (which can be deleted following its replication to the intermediate volume), it is not uncommon to have multiple snapshot volumes associated with a given base volume. These additional snapshot volumes would also be susceptible to copy-on-write overflow due to the volume copy operation writing the entire extent of a given snapshot volume to their associated base volume. Additionally, the use of the intermediate volume scheme entails multiple configuration requests by the controller, user interaction to create the temporary volume, multiple volume copy requests by the controller and the reduced performance associated with each of these issues.
Therefore, it would be desirable to provide a snapshot volume rollback method using a general purpose volume copy operation which writes directly to an associated base volume without inducing copy-on-write overflow in snapshot volumes associated with the base volume.